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(54) Centralized service management system for two-way interactive communication devices in 
data networks 



(57) A system configured to manage and process 
service requests within a data network comprises a link 
server device (114) that is configured to receive a serv- 
ice request from an interactive communication device 
(106), wherein the link server device attaches link server 
information to the service request indicating the opera- 
tional capabilities of the link server device. A server de- 
vice (112) is configured to receive the service request 
from the link server device and supply a service request 
response based upon information in the service request 
and the link server information. The link server device 
executes a service command upon receipt of the service 
request response and supplies a status response to the 
interactive communication device. 
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Description 

FIELD OF THE INVENTION 

[0001] The present invention relates to data commu- 
nications between server computers and client comput- 
ers within the context of data networks. More specifical- 
ly, a method and apparatus for managing two-way inter- 
active communication devices over the data networks 
utilizing a link server; wherein the two-way interactive 
communication devices, such as mobile devices, cellu- 
lar phones, iandline telephones and Internet appliance 
controllers, have generally limited computing resources 
such as computing power, memory and graphical dis- 
play capability. 

BACKGROUND 

[0002] The Internet is a rapidly growing communica- 
tion network of interconnected computers and computer 
networks around the world. Together, these millions of 
connected computers form a vast repository of hyper- 
finked information that is readily accessible by any of the 
connected computers from anywhere at any time. To 
provide mobility and portability of the Internet, wireless 
Internet computing devices were introduced and are ca- 
pable of communicating, via wireless data networks, 
with the computers on the Internet. With the wireless da- 
ta networks, people, as they travel or move about, are 
able to perform, through the wireless computing devic- 
es, exactly the same tasks they could do with computers 
on the Internet. 

[0003] Regular mobile phones can return calls, check 
voice mail or enable users to be available for telecon- 
ferences anywhere at any time. However, new two-way 
interactive communication devices, such as mobile de- 
vices or mobile phones, would meld voice, data, and 
personal digital assistants (PDA) functionality into a sin- 
gle portable device that is not just reactive to calls but 
also proactive, accessing a myriad of public and enter- 
prise information services in the Internet. The evolution 
of the interactive mobile device or mobile phones has 
been evidently fuelled by the demand of users for im- 
mediate access to the information they are looking for 
in the Internet. 

[0004] The client computer or two-way communica- 
tion device, which may constitute a mobile computing 
device, a cellular phone, a Iandline telephone, or an In- 
ternet appliance controller, typically has very limited 
computing and storage capabilities. The limited comput- 
ing and storage capabilities, however, allows for in- 
creased portability and mobility, as such typical two-way 
communication devices are designed small in size, light 
in weight, low in power consumption, and as economi- 
cally as possible. Such designs, having very limited 
computing power and storage capacity, are often clas- 
sified as thin designs, the thin designs are typically 
equivalent to less than one percent of what is provided 
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in a typical desktop or portable computer and the mem- 
ory capacity thereof is gen era I ry less than 250 kilobytes. 
Accordingly, the thin client devices do not have extra 
memory space to store large amount of data. 
5 [0005] Furthermore, currently available thin design 
client computers (thin client) generally only provide for 
the browsing of information services contained on a net- 
work, such as the Internet, due totheir limited computing 
and storage capabilities. Accordingly, the thin client typ- 
io jcally can not support or provide ancillary services, such 
as faxing, printing, downloading, etc., due in part to the 
limited computing and storage capabilities associated 
with these devices. Such ancillary services typically can 
not, and should not, be implemented by the thin client 
75 as they would correspondingly increase the complexity 
of the thin client, thereby increasing the size, weight, and 
power consumption of the thin client. Moreover, such, 
ancillary services require and generate large amount of 
data that should not be sent over wireless networks, due 
to cost, data loss, and logistical considerations. 
[0006] Further such ancillary services are difficult to 
implement on the web server side, as the thin client 
would typically incur a service cost from the web server 
for performing a particular service, such as faxing, on 
behalf of a thin client request. Alternately in the case of 
a print request from a thin client, the web server would 
require access to the thin client's network in order for 
the web server to sent a print request to a thin clients 
designated printer. 

[0007] To illustrate the problem, consider the situation 
in which a thin client wishes to fax an e-mail message 
from a mail service to another destination. One pro- 
posed solution is for the mail service to down bad the 
entire message (with attachments) to the thin client, cre- 
ate a fax image of the e-mail message, and then send 
the fax directly from the thin client to the desired desti- 
nation. The shortcomings of this approach, however, is 
that the entire e-mail message must be downloaded 
over the wireless network, along with any associated at- 
tachments. Further, the thin client must have sufficient 
memory to store the entire e-mail message (with attach- 
ments), must be able to render the e-mail and attach- 
ments as a facsimile image, and must be able to place 
facsimile calls via the voice network. As a result, the 
complexity of the thin client is necessarily increased by 
the corresponding facilities which would be required in 
order to support such operations. Moreover, as new at- 
tachment types are introduced it is unlikely they will be 
supported by the existing thin client, as the thin clients 
are often difficult or impossible to upgrade with new soft- 
ware. 

[0008] Another proposed solution is for the mail serv- 
ice to render the e-mail message and fax it from the mail 
service application to the desired destination. Accord- 
ingly, this would remedy the problem of transferring data 
over the wireless network, thereby reducing the com- 
plexity associated with such a transfer, which would in 
turn allow the operation and design of the thin client to 
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remain relatively simple. The sending of data by fax, in 
the current example, however incurs some type of serv- 
ice cost. Accordingly, the typical service provider will re- 
quire some means to recover the costs associated with 
such a service, typically by charging the user/client a 
service fee, as in the current example, by charging the 
user for each fax sent. As such, the mail service or web 
server would be required to establish a "relationship" (i. 
e.- service account) with each user/client in order to im- 
plement a service fee accounting system for recouping 
associated service fees. This proposed solution, how- 
ever, has limitations in that the user would be required 
to establish a "relationship" (i.e. - service account) with 
every web service for which the user/client wants a cer- 
tain service performed. Further, each web service se- 
lected to provide an ancillary service, such as faxing, 
would have to establish a billing and accounting system 
in order to recover costs associated with providing the 
services, along with establishing an infrastructure for 
providing such services. 

[0009] Thus, there is a great need for providing thin 
clients with the ability to generate requests for data and 
direct the result of such requests to an intermediate de- 
vice or link server which could process the result in ac- 
cordance with a certain request protocol. Such a system 
would allow the thin client to remain simple in design 
and would thereby only require a single "relationship" (i. 
e.- service account) to be established between the thin 
client and the intermediate device or link server. Further, 
the intermediate device or link server would be relatively 
easy to augment in order to provide additional features 
in the future based on a desired service requested by a 
user/client. 

SUMMARY OF THE INVENTION 

[0010] The present invention is directed to a system 
configured to manage and process service requests 
within a data network. The system comprises a link serv- 
er device that is configured to receive a service request 
from an interactive communication device, wherein the 
link server device attaches link server information to the 
service request indicating the operational capabilities of 
the link server device. A server device configured to re- 
ceive the service request from the link server device and 
supply a service request response based upon informa- 
tion in the service request and the link server informa- 
tion. Wherein the link server executes a service com- 
mand upon receipt of the service request response and 
supplies a status response to the interactive communi- 
cation device. 

[0011] In one embodiment of the invention, the serv- 
ice request response comprises a multi-part response, 
the multi-part response comprising service request data 
and the status response. 

[0012] In another embodiment of the invention, the 
status response supplied to the interactive communica- 
tion device contains the service request data. 



[0013] In yet another embodiment of the invention, a 
service device is coupled to the link server device, 
wherein the service device performs the service indicat- 
ed by the service command. 

5 [0014] An object of the present invention is to provide 
thin clients with the ability to generate requests for data 
and direct the result of such requests to an intermediate 
device or link server which can process the result in ac- 
cordance with a certain request protocol. 

io [0015] Another object of the present invention is to 
provide a system that would allow the thin client to re- 
main simple in design and only require a single "rela- 
tionship" (i.e.- service account) to be established be- 
tween the thin client and the intermediate device or link 

*5 server. 

[0016] Yet another object of the present invention is 
provide a link server capable of executing service re r 
quests and providing a variety of ancillary services. 

20 BRIEF DESCRIPTION OF THE DRAWINGS 

[0017] The present invent bn is illustrated by way of 
example in the following drawings in which like referenc- 
es indicate similar elements. The following drawings dis- 
25 close various embodiments of the present invention for 
purposes of illustration only and are not intended to limit 
the scope of the invention. 

[0018] Figure 1 illustrates a schematic configuration 
in which the present invention may be practised. 
30 [0019] Figure 2 illustrates, in a functional block dia- 
gram, an embodiment of a communication system ca- 
pable of implementing the teachings of the present in- 
vention. 

[0020] Figure 3 illustrates an embodiment of the com- 
35 munication system of Figure 2 within the context of 
processing a fax service request. 
[0021] Figure 4 illustrates an embodiment of the op- 
eration of the communication system of Figure 2, via a 
flow diagram, illustrating the operation of the system 
40 within the context of processing a print service request. 

DETAILED DESCRIPTION 

Notation and Nomenclature 

45 

[0022] In the following detailed description of the 
present invention, numerous specific details are set 
forth in order to provide a thorough understanding of the 
present invention. However, it will become obvious to 

50 those skilled in the art that the present invention may be 
practised without these specific details, in other instanc- 
es, well known methods, procedures, components, and 
circuitry have not been described in detail to avoid un- 
necessarily obscuring aspects of the present invention. 

55 [0023] The detailed description of the present inven- 
tion in the following are presented largely in terms of 
procedures, steps, logic blocks, processing, and other 
symbolic representations that resemble of data 
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processing devices coupled to networks. These process 
descriptions and representatbns are the means used 
by those experienced or skilled in the art to most effec- 
tively convey the substance of their work to others 
skilled in the art. The present invention is a centralized 
service management system for two-way interactive 
communication devices in data networks. The method 
and apparatus along with the architecture to be de- 
scribed in detail below is a self-consistent sequence of 
processes or steps leading to a desired result. These 
steps or processes are those requiring physical manip- 
ulations of physical quantities. Usually, though not nec- 
essarily, these quantities may take the form of electrical 
signals capable of being stored, transferred, combined, 
compared, displayed and otherwise manipulated in a 
computer system or electronic computing devices. It 
proves convenient at times, principally for reasons of 
common usage, to refer to these signals as bits, values, 
elements, symbols, operations, messages, terms, num- 
bers, or the tike. It should be borne in mind that all of 
these similar terms are to be associated with the appro- 
priate physical quantities and are merely convenient la- 
bels applied to these quantities. Unless specifically stat- 
ed otherwise as apparent from the following description, 
it is appreciated that throughout the present invention, 
discussions utilizing terms such as "processing" or 
"computing 0 or Verifying" or "displaying" or the like, re- 
fer to the actions and processes of a computing device 
that manipulates and transforms data represented as 
physical quantities within the computing device s regis- 
ters and memories into other data similarly represented 
as physical quantities within the computing device or 
other electronic devices. 

The Preferred Embodiment 

[0024] Referring nowtothe drawings : in which like nu- 
merals refer to like parts throughout the several views. 
Figure 1 illustrates a schematic configuration in which 
the present invention may be practised. A data network 
100 comprises an airnet 102 that is generally called a 
wireless network and a landnet 104 that is generally a 
landiine network, each acting as a communication me- 
dium for data transmission there through. Airnet 102, in 
which the data transmission is via the air, is sometimes 
referred to as a carrier network because each airnet is 
controlled and operated by a carrier, for example AT&T 
and GTE, each having its own communication scheme, 
such as CDPD, CDMA, GSM and TDMA for airnet 1 02. 
The landnet 104 or Internet, used interchangeably here- 
in, may be the Internet, the Intranet, or other private net- 
works or databases. 

[0025] Referenced by 1 06 is one of the two-way inter- 
active communication devices that can be a mobile de- 
vice, a cellular phone, a landiine telephone or a wireless 
capable remote controller, capable of communicating, 
via airnet 1 02, with an antenna 1 08 that also represents 
a carrier infrastructure. It is generally understood that 



the carrier infrastructure 108 serves simultaneously a 
plurality of the two-way interactive communication de- 
vices, of which only one mobile device 106 is shown in 
the figure. Similarly, connected to Internet 104 areaplu- 

s rality of desktop personal computers (PC) 1 1 0 and a plu- 
rality of server computers 112, though only one repre- 
sentative, respectively, is shown in the figure. PC 110, 
as shown in the figure, may be a personal computer SPL 
300 from NEC Technologies Inc. which runs a HTML 

io Web browser via the Internet 104 using HTTP to access 
information stored in web server 112 that may be a work- 
station from SUN Microsystems Inc. It is understood to 
those skilled in the art that PC 110 can store accessible 
information therein so as to become a web server as 

15 well. 

[0026] Between the internet 104 and the airnet 102 
there is a link infrastructure that comprises a link server 
device 1 1 4 and the carrier infrastructure 1 08. Link server 
device 114, also referred to as a gateway server, may 

20 be a workstation or a personal computer configure to 
perform a mapping or translation function, for example, 
mapping from one protocol to another, thereby the mo- 
bile device 106 can be in communication with any one 
of the servers 112 or the PCs 110, respectively via the 

2S carrier infrastructure 108. Additionally, as will be dis- 
cussed in further detail in the following description, the 
link server device 114 is configured to execute a function 
or provide a service in connection with service request 
data which is received in response to a service request 

30 initiated by a user of the mobile device 106. 

[0027] The communication protocol in the Internet 
104 is the well known HyperText Transfer Protocol (HT- 
TP) or HTTPS, a secure version of HTTP, and runs on 
TCP and controls the connection of a well known Hy- 

3S perText Markup Language Web browser, or HTML Web 
browser in PC 110, to Web server 112, and the ex- 
change of information there between. The communica- 
tion protocol between mobile device 106 and link server 
114 via airnet 102 is Handheld Device Transport Proto- 

40 col (HDTP), (formerly known as Secure Uplink Gateway 
Protocol (SUGP)), which preferably runs on User Data- 
gram Protocol (UDP) and controls the connection of a 
HDML Web browser in mobile device 106, to server 114, 
where HDML stands for Handheld Device Markup Lan- 

45 guage. HDML, similar to that ot HTML, is a tag based 
document language and comprises a set of commands 
or statements specified in a card that specifies how in- 
formation displayed on a small screen of the mobile de- 
vice 106. Normally a number of cards are grouped into 

50 a deck that is the smallest unit of HDML information that 
can be exchanged between the mobile device 106 and 
the link server 114. The specifications of HDTP, entitled 
"HDTP Specification", and HDML, entitled "HDML 2.0 
Language Reference" are enclosed and incorporated 

55 herein by reference in its entirety. The HDTP is a ses- 
sion-level protocol that resembles HTTP but without in- 
curring the overhead thereof and is highly optimized for 
use in thin devices, such as the mobile devices, that 
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have significantly less computing power and memory 
than that in a desktop personal computer. Further it is 
understood to those skilled in the art that the UDP does 
not require a connection to be established between a 
client and a server before information can be ex- 
changed, which eliminates the need of exchanging a 
large number of packets during a session creation be- 
tween a client and a server. Exchanging a very small 
number of packets during a transaction is one of the de- 
sired features for a mobile device with very limited com- 
puting power and memory to effectively interact with a 
landline device. 

[0028] Further the carrier infrastructure 1 08 and mo- 
bile devices, in Figure 1, represents a wireless network 
system that may be a GSM or CDPD network system 
depending on the transmission protocol used by the ear- 
ner in the network system. A wireless network system 
is generally composed of three broad parts; mobile sta- 
tions a base station and an operation and maintenance 
center. The mobile stations are, for example, a plurality 
of the mobile devices carried by users, the base station 
controls radio or telecommunication links with the mo- 
bite devices. The operation and maintenance center 
comprises a central component that is a mobile switch- 
ing center that performs the switching of calls between 
the mobile devices and other fixed or mobile network 
users. Further the operation and maintenance center 
manages mobile services, such as authentication and 
oversees the proper operation and setup of the GSM 
network. Each of the hardware components in the three 
broad parts are known to those skilled in the art and is 
not to be described herein to avoid unnecessarily ob- 
scuring aspects of the present invention. 
[0029] To facilitate the description of the disclosed 
system, however, it is deemed necessary to recite some 
of the features in mobile device 106 that make the dis- 
closed system work more efficiently. According to one 
embodiment, mobile phone 106 comprises a display 
screen 116 and a keyboard pad 118 that allow a user 
thereof to communicate interactively with the mobile 
phone. The hardware components including a micro- 
controller, a ROM and a RAM, referring to working mem- 
ory, in mobile phone 106 are known to those skilled in 
the art. The compiled and linked processes of the 
present invention are typically stored in the ROM as a 
client module that causes mobile device 106 to operate 
with linkserver 114. With display screen 116 and keypad 
1 18, a user of mobile device 106 can interactively com- 
municate with link server 114 over airnet 102. Upon ac- 
tivation of a predetermined key sequence utilizing key- 
pad 118, for example, the microcontroller initiates a 
communication session request to link server 114 using 
the client module in the ROM. Upon establishing the 
communication session, mobile device 106 typically re- 
ceives a single HDML deck from link server 114 and 
stores the deck as cached in the RAM. As described 
above, an HDML deck comprises one or more cards and 
each card includes the information required to generate 



a screen display on display screen 116. The number of 
cards in a card deck is selected to facilitate efficient use 
of the resources in mobile device 106 and in airnet net- 
work 102. 

5 [0030] Figure 2 illustrates a simplified functional block 
diagram of a communication system 200 capable of im- 
plementing the teachings of the present invention. A 
Web server device 202, or simply server device 202, 
provides accessible information to other computing de- 

10 vices via Internet 204. A mobile device or client device 
206 accesses, over an airnet 210, the information in web 
server device 202 via a link or link server device 208 
that is coupled to Internet 204. It should be noted that 
the communication between mobile device 206 and link 

?5 server 208 is via the carrier infrastructure which is not 
part of the invention, and therefore not shown in Figure 
2, so as to avoid unnecessarily obscuring the inventive 
aspects of the present invention. 
[0031] Further, to avoid possible ambiguities in further 

20 description of the present invention, a server device, 
such as server device 202 and link server device 208, 
means a piece of hardware equipment that comprises 
one or more microprocessors, working memory, buses 
and necessary interface and other components that are 

2S familiar to those skilled in the art, while a server module 
means compiled and linked processes of the disclosed 
system loaded into the working memory to perform des- 
ignated designed functions, according to the invention, 
through the parts and components in the server device. 

so The same distinction is equally applied to mobile devic- 
es, referred to, for example, client device 206, and the 
client module as stated before. 

[0032] With reference to Figure 2, the user of the client 
device 206 first initiates a communication session re- 

3S quest via the client device 206, through airnet 210, to 
the link server 208. Once the communication session is 
established, the user of the client device 206 selects or 
inputs service selection data, which corresponds to se- 
lect data contained in a network or database, into a se- 

40 lectable user interface contained in the client device 
206. Each selectable user interface is associated with 
a corresponding service application, which is likewise 
selectable, used in the processing of different service 
requests. As such, the user of the client device 206 se- 

45 tects a task or function, which is to be applied to select 
data, by selecting or inputting the corresponding service 
selection data associated with the desired task or func- 
tion into the user interface. Correspondingly, the client 
device 206 generates a service request 21 2 based upon 

so the service selection data selected from, or inputted into, 
the user interface of the client device 206. 
[0033] The service request 21 2 contains service in- 
formation, generated from the service selection data, 
comprised of identification information corresponding to 

55 the select data, such as a URL (Universal Resource Lo- 
cator), or other identifier, which identifies or describes 
the select data or information contained in a particular 
database or network. Additionally, the service informa- 
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tion indicates the type of service requested (i.e.: print, 
fax, download, etc.), the identification of the data type 
associated with the service request (i.e.: e-mail mes- 
sage, HTML document, data file, etc.), and the destina- 
tion for a response to the service request (fax number 5 
and location, printer identification, computer or data- 
base identification, etc.). 

[0034] Upon generation of the service request 21 2 : 
the client device 206 supplies or transmits the service 
request 21 2 ; containing the service information, to the 10 
link server 210. Accordingly, upon receipt of the service 
request 212, the link server 208 converts the transfer 
protocol associated with the service request 212 from 
an HDTP protocol to an HTTP protocol. Further, the link 
server 208 attaches link server information to the serv- is 
ice request 212 which indicates the types of services or 
functions that the link server device 208 is capable of 
processing or executing with respect to the selected 
service request 212. Additionally, the link server infor- 
mation identifies the content-types of data that the link 20 
server device 208 is able to accept and process. 
[0035] The service request 212, containing the serv- 
ice information and link server information, is then for- 
warded, via the Internet 204, from the link server device 
208 to the server device 202. Accordingly, the server 25 
device 202 selects and uses a particular service appli- 
cation 216 associated with the service request 212 in 
order to process the service request 212. Correspond- 
ingly, the server device 202, through the associated 
service application 216, uses the service information 30 
contained in the service request 21 2 to locate the select 
data or service request data, in an associated network 
or database, which corresponds to the identification in- 
formation contained in the service information. 
[0036] The server device 202 then supplies the serv- 35 
ice request data to a selected service application 216 
which processes the service request data in accordance 
with the link server information and the service informa- 
tion contained in the service request 212. As mentioned 
above, the link server information indicates the types of 40 
services or functions, associated with the service re- 
quest 21 2, that the link server device 208 is capable of 
processing, in addition to the content-types of data that 
the link server device 208 is able to accept and process. 
Correspondingly, the service application 216, after lo- 45 
eating the service request data, processes the service 
request data into an appropriate format for use by the 
link server 208, based upon one of the content-types of 
data that the link server device 208 is able to accept and 
process. Further, the server device 202, via the service 50 
application 216, uses the service information when for- 
matting the service request data to indicate the type of 
service requested (service command), to the link server 
208. 

[0037] After the service application 216 has proc- 55 
essed the service request data into an appropriate for- 
mat for use by the link server 208, the server device 
202,through service application 216, generates a status 



response 220 (HDML response) which is eventually 
supplied to the client device 206, and displayed to the 
user thereof, upon completion of the service request 
21 2. The status response 220 supplies the client device 
206 with information indicating that the service request 
21 2 has been fully processed by the link server 20S. Ac- 
cordingly, the server device 202 combines the service 
request data (i.e.: actual service request data corre- 
sponding to the identification information) with the status 
response 220 into a multi-part response 218 or service 
request response. The multi-part response 218 or serv- 
ice request response, is supplied to the link server de- 
vice 208 as an HTTP response, via Internet 204. As in- 
dicated above, the multi-part response 218 is formatted 
into one of the content-types of data that the link server 
device 208 is able to accept and process. Further, the 
multi-part response 218 indicates the type of service 
(service command) to be executed in association with 
the service request data. Accordingly, the multi-part re- 
sponse 218 contains a status response 220 (HDML re- 
sponse), the service request data which is formatted 
with respect to the content-type, and a service com- 
mand. In an alternate embodiment, the content-type for- 
mat, rather then the service command, could be used 
to identify the type of service to be performed in asso- 
ciation with the service request data. 
[0038] Upon receipt of the multi-part response 218, 
the link server 208 examines the multi-part response 
21 8 to determine the type of service (service command) 
to be performed in association with the service request 
data. Accordingly, the link server 208 decomposes the 
multi-part response 218 into the service request data 
222 and the status response 220. Upon determination 
of the type of service requested (service command) , the 
link server 208 then executes the service command in- 
dicated in the multi-part response 218. Correspondingly, 
the link server 208 forwards or supplies the service re- 
quest data 222 to a corresponding proxy service or serv- 
ice device 214 that is configured to perform the particu- 
lar service (service command) indicated in the multi-part 
response 218. After the execution of the service com- 
mand, the link server 208 supplies the status response 
220 to the client device 206, the status response 220 
indicating the original service request 212 has been fully 
processed. 

[0039] Alternately, a copy of the service request data 
222 could be supplied to the client device 206, along 
with the status response 220, to allow the user of the 
client device 206 to view the service request data 222. 
[0040] Figure 3 illustrates an example of the process- 
ing of a service request using the functional block dia- 
gram of Figure 2. More specifically, Figure 3 illustrates 
the processing of a "fax" service request for an e-mail 
message using a mail manager application. Although 
the following example is illustrated in the context of a 
fax service request, it is understood that the present in- 
vention is applicable to a variety of different service re- 
quests and is not meant to limit the applicability of the 
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present invention to illustrated type of service request. 
Further, the present example is directed to the retrieval 
of an e-mail message from a network, however, it is un- 
derstood that the present invention is capable of retrieve 
any type of data from any type of network. s 
[0041] With reference to Figure 3, the user of the client 
device 206 first initiates a communication session re- 
quest via the client device 206, through airnet 210, to 
the link server 208. Once the communication session is 
established, the user of the client device 206 selects or io 
inputs service selection data into a selectable user in- 
terface contained in the client device 206. The selecta- 
ble user interface in the current example would com- 
prise a fax user interface, wherein the fax user interface 
has an corresponding service application, in this case a is 
mail manager application 216, used in the processing 
of different fax service requests. 

[0042] Accordingly, the mail manager application 216 
is configured to provide a fax user interface for inputting 
or selecting information regarding the faxing of a partic- 20 
ular e-mail message. Therefore, the user inputs or se- 
lects fax service selection data via the fax user interface, 
wherein the fax service selection data corresponds to 
the select e-mait message contained in a particular net- 
work or database. In the user interface, the particular e- zs 
mail message is selected and the fax number corre- 
sponding to a desired fax location is entered. 
[0043] As such, the user of the client device 206 se- 
lects a particular fax task or function, which is to be ap- 
plied to the e-mail message, by selecting or inputting the 30 
corresponding fax service selection data associated 
with the desired fax task or function into the fax user 
interface. Correspondingly, the client device 206 gener- 
ates a fax service request 212 based upon the fax serv- 
ice selection data selected from, or inputted into, the fax 35 
user interface of the client device 206. The fax service 
request 212 indicates that the user of the client device 
206 has requested a fax service to be performed in con- 
nection with particular data (i.e.: e-mail message). 
[0044] The fax service request 212 contains service 
information, generated from the fax service selection 
data, comprised of identification information corre- 
sponding to the select e-mail, such as a URL (Universal 
Resource Locator), or other identifier, which identifies 
or describes the e-mail message contained in a partic- 
ular network or database. Additionally, the service infor- 
mation indicates the type of service requested (i.e.: fax 
service), the identification of the data type associated 
with the service request (i.e.: e-mail message), and the 
destination for a response to the service request (fax 
number and location). 

[0045] Upon generation of the fax service request 
212, the client device 206 supplies or transmits the fax 
service request 21 2, containing the service information, 
to the link server 210. Accordingly, upon receipt of the 
fax service request 21 2, the link server 208 converts the 
transfer protocol associated with the fax service request 
212 from an HDTP protocol to an HTTP protocol. Fur- 
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ther, the link server 208 attaches link server information 
to the fax service request 21 2 which indicates the types 
of fax services or functions that the link server device 
304 is capable of processing or executing with respect 
to the selected fax service request 21 2. Additionally, the 
link server information identifies the content-types of fax 
data that the link server device 208 is able to accept and 
process. 

[0046] The fax service request 212, containing the 
service information and link server information, is then 
forwarded : via the Internet 204, from the link server de- 
vice 208 to the server device 202. Accordingly, the serv- 
er device 202 selects and uses a particular service ap- 
plication associated with the service request 212, which 
in the present example is a mail manager application 
216, in order to process the fax service request 212. Ac- 
cordingly, the server device 202, through the mail man- 
ager application 216, uses the service information con- 
tained in the fax service request 21 2 to locate the e-mail 
message, also known as service request data, in an as- 
sociated network or database, such as a mail manager 
database. In the present example, for instance, the serv- 
er device 202, via the mail manager application 216 lo- 
cates and retrieves the e-mail message associated with 
the identification information from a database corre- 
sponding to the mail manager application 216. There- 
fore, the server device 202, through the mail manager 
application 216, locates the e-mail message or service 
request data, which corresponds to the identification in- 
formation contained in the service information, from an 
associated database, such as a mail manager data- 
base. 

[0047] The server device 202 then supplies the serv- 
ice request data (e-mail message) to the selected serv- 
ice application which processes the service request da- 
ta in accordance with the link server information and the 
service information contained in the fax service request 
21 2. As mentioned above, the link server information in- 
dicates the types of services or functions, associated 
with the service request 212, that the link server device 
208 is capable of processing, in addition to the content- 
types of data that the link server device 208 is able to 
accept and process. Correspondingly, the mail manager 
application 21 6, after locating the service request data, 
processes the service request data into an appropriate 
format for use by the link server 208, based upon one 
of the content-types of data that the link server device 
208 is able to accept and process. Further, the server 
device 202, via the mail manager application 216, in- 
cludes the service information, or other similar data, 
when formatting the service request data to indicate the 
type of service requested (service command) to the link 
server 208. 

[0048] In the present example, for instance, the mail 
manager application 216 associated with the server de- 
vice 202 would locate and retrieve the e-mail message 
associated with the particular identifier or URL from an 
applicable database identified by the mail manager ap- 
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plication 216. Upon locating and retrieving the e-mail 
message corresponding to the identifier contained in the 
fax service request 212, the mail manger application 
216 generates a facsimile form of the selected e-mail 
message in one of the content-types that the link server 
device 208 is able to accept and process. Additionally, 
the mail manager application 216 may be configured to 
generate a fax cover page which contains details re- 
garding the fax service request 21 2,suchas the sender's 
name, subject matter, fax number, or any other type of 
desired data. Therefore, the selected e-mail message 
has been formatted in accordance with the parameters 
specified in the original fax service request 212, result- 
ing in formatted fax service request data. Further, the 
server device 202, via the mail manager application 21 6, 
includes the service informatioa or other similar data, 
associated with the fax service request 212, when for- 
matting the service request data to indicate the type of 
service requested (service command) to the link server 
208. 

[0049] The mail manager application 216 then proc- 
esses the service request data into an appropriate for- 
mat, with the service command information included, for 
use by the link server 208. Correspondingly, the mail 
manager application 216 generates a status response 
220 (HDML response) which is eventually supplied to 
the client device 206, and displayed to the user thereof, 
upon final execution of the fax service request 21 2. The 
status response 220 supplies the client device 206 with 
information indicating that the fax service request 212 
has been fully processed by the link server 208. Accord- 
ingly, the server device 202 combines the fax service 
request data (i.e.: formatted fax service request data 
containing the service command) with the status re- 
sponse 220 into a multi-part response 218, also known 
as a service request response. The multi-part response 
218 or service request response is supplied to the link 
server device 208 as an HTTP response, via Internet 
204. As indicated above, the multi-part response 218 is 
formatted into one of the content-types of data that the 
link server device 208 is able to accept and process. 
Further, the multi-part response 218 indicates the type 
of service request (service command) to be executed in 
association with the fax service request data. Accord- 
ingly, the multi-part response 218 contains a status re- 
sponse 220 (HDML response), the fax service request 
data which is formatted with respect to the content-type 
(fax data format), and service command (order to fax). 
In an alternate embodiment, the formatted content-type 
(fax data format), rather then the service command (or- 
der to fax), could be used to identify the type of service 
to be performed in association with the fax service re- 
quest data. 

[0050] Upon receipt of the multi-part response 218, 
the link server 208 examines the multi-part response 
218 to determine the type of service to be performed 
(service command) in association with the fax service 
request data. Accordingly, the link server 208 decom- 



poses the multi-part response 218 into the fax service 
request data 222 and the status response 218. Upon 
determination of the type of service requested (service 
command), the link server 203 then executes (i.e. : order 

5 to fax the e-mail message) the particular service (serv- 
ice command) indicated in the multi-part response 218. 
Correspondingly the link server 208 forwards or sup- 
plies the fax service request data 222 to a corresponding 
proxy service or service device 21 4 that is configured to 

10 perform the particular fax service (service command) in- 
dicated in the multi-part response 218. In the present 
example, the proxy service or service device 214 would 
be a device configu red to fax the fax service request da- 
ta 222 to the fax location specified in the service com* 

is mand. After the execution of the particular fax service 
(service command) indicated in the multi-part response 
218, the link server 208 supplies the status response 
220 to the client device 206, the status response 220 
indicating that the original fax service request 212 has 

20 been fully processed. 

[0051] Alternately, a copy of the fax service request 
data 222 could be supplied to the client device 206, in 
addition to the status response 220, to allow the user of 
the client device 206 to view the fax service request data 

2S 222. 

[0052] Figure 4 illustrates, in a flow diagram, an em- 
bodiment of a method for processing a service request 
within the context of the functional block diagram of Fig- 
ure 2. More specifically, Figure 4 illustrates the process- 

30 ing of a HTML document print service request (print 
service request). Although the following example is il- 
lustrated in the context of a print service request, it is 
understood that the present invention is applicable to a 
variety of different service requests and is not meant to 

35 limit the applicability of the present invention to this type 
of service request. Further, the present example is di- 
rected to the retrieval and printing ol an HTML document 
from a network, however, it is understood that the 
present invention is capable of retrieve any type of data 

40 from any type of network. 

[0053] With reference to Figure 4, at 400, the user of 
the client device 206 first initiates a communication ses- 
sion request via the client device 206, through aimet 
210, to the link server 208. Once the communication 

45 session is established, the user of the client device 206 
selects or inputs service selection data into a selectable 
user interface contained in the client device 206. The 
selectable user interface in the current example would 
comprise a HTML document print user interface (print 

so user interface), wherein the print user interface has a 
corresponding service application, in this case a print 
manager application 216, used in the processing of dif- 
ferent service requests. Accordingly, the print manage- 
ment application 21 6 is configured to provide a print user 

55 interface for inputting or selecting information regarding 
the printing of a particular HTML document. Accordingly, 
the user would input or select print service selection data 
at the print user interface, wherein the print service se- 
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lection data corresponds to the select HTML document 
contained in an associated network or database. In the 
print user interface, the particular HTML document is se- 
lected and the printer identification (Printer ID) corre- 
sponding to a desired printer location is entered. 
[0054] As such, the user of the client device 206 se- 
lects a particular print task or function to be applied to 
the HTML document by selecting or inputting the corre- 
sponding print service selection data associated with 
the desired print task or function into the print user in- 
terface. Correspondingly, the client device 206 gener- 
ates a print service request 212 based upon the print 
service selection data selected from, or inputted into, 
the print user, interface of the client device 206. The print 
service request 212 indicates that the user of the client 
device 206 has requested a print service to be per- 
formed in connection with particular data (i.e.: HTML 
document). 

[0055] The print service request 21 2 contains service 
information, generated from the print service selection 
data, comprised of identification information corre- 
sponding to the HTML document, such as a URL (Uni- 
versal Resource Locator), or other identifier, which iden- 
tifies or describes the HTML document contained in a 
particular network or database. Additionally, the service 
information indicates the type of service requested (i.e.: 
print service), the identification of the data type associ- 
ated with the service request (i.e.: HTML document), 
and the destination for a response to the service request 
(Printer ID and location). 

[0056] At 405,' upon generation of the print service re- 
quest 212, the client device 206 supplies or transmits 
the print service request 212, containing the service in- 
formation, to the link server 210. Accordingly, upon re- 
ceipt of the print service request 21 2, the link server 208 
converts the transfer protocol associated with the print 
service request 21 2 from an HDTP protocol to an HTTP 
protocol. Further, the link server 208 attaches link server 
information to the print service request 212 which indi- 
cates the types of print services or functions that the link 
server device 208 is capable of processing or executing 
with respect to the selected print service request 212. 
Additionally, the link server information identifies the 
content-types of print data that the link server device 208 
is able to accept and process. 

[0057] Next at 410, the print service request 212, con- 
taining the service information and link server informa- 
tion, is then forwarded, via the Internet 204, from the link 
server device 208 to the server device 202. Accordingly, 
the server device 202 selects and uses a particular serv- 
ice application, which in the present example is the print 
manager application 21 6, associated with the print serv- 
ice request 212, in order to process the print service re- 
quest 212. Accordingly, the server device 202, through 
the print manager application 216, uses the service in- 
formation contained in the print service request 212 to 
locate the HTML document or service request data, in 
an associated network or database, such as a HTML 
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document database or the Internet 204. As such, the 
print manager application 216 can be configured to uti- 
lize a web browser service to obtain the desired HTML 
document from the Internet 204. In the present example, 

s for instance, the server device 202, via the print manag- 
er application 216, locates and retrieves the HTML doc- 
ument associated with the identification information 
from a database corresponding to the print manager ap- 
plication 216, or alternately from the Internet 204. 

10 Therefore, the server device 202, through the print man- 
ager application 216, locates the HTML document, also 
known as service request data, which corresponds to 
the identification information contained in the service in- 
formation. 

is [0058] At 415, The server device 202 supplies the 
service request data (HTML document) to the print man- 
ager application 216 which processes the service re- 
quest data in accordance with the link server information 
and the service information contained in the print service 

20 request 212. As mentioned above, the link server infor- 
mation indicates the types of services or functions, as- 
sociated with the service request 21 2, that the link serv- 
er device 208 is capable of processing, in addition to the 
content-types of data that the link server device 208 is 

25 able to accept and process. Correspondingly, the serv- 
ice application, after locating the service request data, 
processes the service request data into an appropriate 
format for use by the link server 208, based upon one 
of the content-types of data that the link server device 

30 208 is able to accept and process. Further, the server 
device 202 includes the service information when for- 
matting the service request data to indicate the type of 
service requested (service command) to the link server 
208. 

35 [0059] In the present example, for instance, the print 
manager application 216 associated with the server de- 
vice 202 would locate and retrieve the HTML document 
associated with the particular identifier or URL from a 
database corresponding to the print manager applica- 

40 tion 216, or alternately from a network, such as the In- 
ternet 204. Upon locating and retrieving the HTML doc- 
ument corresponding to the identification information 
contained in the print service request 21 2, the print man- 
ger application 216 generates a data print form of the 

45 selected HTML document in one of the content-types 
that the link server device 208 is able to accept and proc- 
ess. Additionally, the print manager application 21 6 may 
be configured to generate a print cover page which con- 
tains details regarding the print service request 212, 

50 such as the sender's name, subject matter, printer ID, 
or any other type of desired data. Therefore, the select- 
ed HTML document has been formatted in accordance 
with the parameters specified in the original print service 
request 212, resulting in formatted print service request 

ss data. Further, the server device 202, via the print man- 
ager application 216, includes the service information, 
associated with the print service request 212, when for- 
matting the print service request data to indicate the type 
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of service requested (service command) to the link serv- 
er 208. 

[0060] At 420, the print manager application 216 proc- 
esses the print service request data into an appropriate 
format, with the service command information included, 
for use by the link server 208. Correspondingly, the print 
manager application 216 generates a status response 
220 (HDML response) which is eventually supplied to 
the client device 206, and displayed to the user thereof, 
upon final executbn of the service request 21 2. The sta- 
tus response 220 supplies the client device 206 with in- 
formation indicating that the print service request 212 
has been fully processed by the link server 208. Accord- 
ingly, the server device 202 combines the print service 
request data (i.e.: formatted print service request data 
and service information) with the status response 220 
into a multi-part response 218, also known as a service 
request response. The multi-part response 218 or serv- 
ice request response is supplied to the link server device 
208 as an HTTP response, via Internet 204. As indicated 
above, the multi-part response 218 is formatted into one 
of the content-types of data that the link server device 
208 is able to accept and process. Further, the multi- 
part response 21 8 indicates the type of service request 
(service command) to be executed in association with 
the print service request data. Accordingly, the multi- 
part response 218 contains a status response 220 
(HDML response), the print service request data which 
is formatted with respect to the content-type (print data 
format), and service command (order to print). In an al- 
ternate embodiment, the formatted content-type (print 
data format), rather then the service command (order to 
print), could be used to identify the type of service (serv- 
ice command) to be performed in association with the 
print service request data. 

[0061] Accordingly, at 425, the multi-part response 
218 is then supplied to the link server 208, wherein the 
link server 208 examines the multi-part response 218 to 
determine the type of service to be performed (service 
command) upon the print service request data. Accord- 
ingly, the link server 208 decomposes the multi-part re- 
sponse 218 into the print service request data 222 and 
the status response 220. Upon determination of the type 
of service requested (service command), the link server 
208 then executes (i.e.: order to print HTML document) 
the particular service indicated (service command) in 
the multi-part response 218. Correspondingly, the link 
server 208 forwards or supplies the print service request 
data 222 to a corresponding proxy service or service de- 
vice 21 4 that is configured to perform the particular print 
service indicated (service command) in the multi-part re- 
sponse 218. In the present example, the proxy service 
or service device 214 would be a device configured to 
print the print service request data 222 to the printer ID 
and location specified in the service command. After the 
execution of the particular print service indicated in the 
multi-part response 21 8, the link server 208 supplies the 
status response 220 to the client device 206, the status 



18 

response 220 indicating that the original service request 
21 2 has been fully processed. 

[0062] Alternately, a copy of the print service request 
data 222 could be supplied to the client device 206, in 
5 addition to the status response 220, to allow the user of 
the client device 206 to view the print service request 
data 222. 

[0063] The present invention has been described in 
sufficient detail with a certain degree of particularity. It 

10 is understood to those skilled in the art that the present 
disclosure of embodiments has been made by way of 
example only and that numerous changes in the ar- 
rangement and combination of parts as well as steps 
may be resorted without departing from the spirit and 

*5 scope of the invention as claimed. Accordingly, the 
scope of the present invention is defined by the append- 
ed claims ratherthan the forgoing description of .embod- 
iments. 



1. A method of managing and processing service re- 
quests within a data network, the method compris- 
ing: 

generating a service request upon receiving a 
request from a wireless network, the rr-qusst 
originating from an interactive mobile commu- 
nication device coupled to the wireless net- 
work; 

forwarding the service request to a server de- 
vice configured to supply a service request re- 
sponse based upon information contained in 
the service request; and 
executing a service command upon the receipt 
of the service request response. 

2. A method of claim 1 , wherein the service request is 
to output data from the server device to a terminal 
chosen by a user of the interactive mobile commu- 
nication device. 

3. A method of claim 2, wherein the service request 
response comprises a mu Iti-part response compris- 
ing service request data and a status response. 

4. A method of claim 3, said method further comprising 
forwarding the status response to the interactive 
mobile communication device upon said executing 
a service command being executed. 

5. A method of any preceding claim wherein the serv- 
ice command indicates a service to be executed in 
association with the service request data. 

6. A method of claim 5, wherein a status response is 
supplied to the interactive communication device 
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upon execution of the service command. 

7. A method of managing and processing service re- 
quests within a data network, the method compris- 
ing: 



5 



receiving an input from a user to output service 
request data to a terminal, the service request 
data accessible from a server device coupled 
to a landnet; 10 
generating a service request in response to the 
input, the service request comprising an ad- 
dress identifier identifying a link server remote- 
ly located and coupled between a wireless net- 
work and the landnet; and 15 
sending the service request to the link server 
through the wireless network. 

8. A method of claim 7, wherein thelerminal is a print- 
ing device accessible nearby so that the service re- 20 
quest data output from the terminal can be viewed. 

9. A method of claim 7 or 8, wherein the service re- 
quest data are fetched from the server device to the 

link server through the landnet and the link server 25 
is configured to supply the service request data to 
the terminal for outputting. 

10. A method of any one of claims 7 to 9, the method 
further comprising: 30 
receiving a status response from the link server 
when the service request data are successfully out- 
put on the terminal. 

35 
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